-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RangeControl: Add support for large 40px number input size #49105
Conversation
Size Change: +72 B (0%) Total Size: 1.44 MB
ℹ️ View Unchanged
|
Flaky tests detected in 34f8cf7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5346384047
|
packages/components/src/range-control/styles/range-control-styles.ts
Outdated
Show resolved
Hide resolved
packages/components/src/range-control/styles/range-control-styles.ts
Outdated
Show resolved
Hide resolved
Hey @richtabor , just checking if you need any help with this PR or if you put it on hold for any specific reasons? |
Sorry, just got caught up on other fronts. Feel free to take over if you'd like. |
Picked this PR up today, I'll wrap up the rest of the necessary changes 👍 |
Let us know when it's ready for a new review. 👍 |
I've taken a pass at all outstanding comments - let me know if there's any new or updated feedback! |
packages/components/src/range-control/styles/range-control-styles.ts
Outdated
Show resolved
Hide resolved
packages/components/src/range-control/styles/range-control-styles.ts
Outdated
Show resolved
Hide resolved
packages/components/src/range-control/styles/range-control-styles.ts
Outdated
Show resolved
Hide resolved
Okay, I've addressed the latest pass of feedback (sorry for the delayed turnaround). I think that should address everything, unless we want to do away with the increased width discussed here. Based on @jasmussen's answers (thanks for those!) it looks like we could go either way on that for now. |
I'll defer to Rich, but happy to provide a green check when things settle! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed some minor non-blocking things, but otherwise looks good to go. Thanks for taking over, Chad!
size = 'default', | ||
}: Pick< NumberControlProps, 'size' > ) => { | ||
const sizes = { | ||
small: space( 16 ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can remove this because the small
case will never happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad on this one as well! This is also the result of a change that I suggested to clean up styles and types a bit, small
is there to the sizes
object has, as keys, all possible values that of size
prop from NumberControl
.
Feel free to make changes as needed :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. That only got added when we decided to re-use the NumberControl
prop type instead of typing this bit locally. Can remove the small
case, but I had to get a little creative with the typing as a result. 24190be
Edit: this might be a moot point if we can scrip this logic altogether
/* TODO: remove after removing the __next40pxDefaultSize prop */ | ||
${ rootMinHeight } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a stylistic thing, but as a courtesy for when we actually have to remove the temporary __next*
props, I find it cleaner to structure the code so that the ! __next
case is already handled as the exception case.
For example:
/* TODO: remove after removing the __next40pxDefaultSize prop */ | |
${ rootMinHeight } | |
min-height: 40px; | |
${ deprecatedHeight }; |
where deprecatedHeight
only handles the ! __next40pxDefaultSize
case. The clean up will be easier this way. (Actual example)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I had actually suggested Chad to write code this way!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// @todo: Refactor RangeControl with latest HStack configuration | ||
// @wordpress/components/ui/hstack. | ||
export const InputNumber = styled( NumberControl )` | ||
display: inline-block; | ||
font-size: 13px; | ||
margin-top: 0; | ||
width: ${ space( 16 ) } !important; | ||
${ inputNumberWidth }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better/possible to use the __unstableInputWidth
prop on NumberControl rather than a CSS override?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to work well for me when testing in Storybook. Was 6fec45f along the lines you were thinking? Just to make sure I've implemented it properly.
If so, it has the added benefit of simplifying all of that inputWidth
logic and typing!
Looking good! |
Thanks @mirka and @richtabor! Lena, I know you dropped a green checkmark after your last review but I've made a few changes based on your feedback, so I'll hold up for a final 👍 and then I'll update the changelog and get this merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thank you!
It's a bit weird that rangeHeightValue = 30
is still always used for some margin-top calculations, and ideally that should be refactored to make sense, but I don't consider that a blocker for this PR. Especially since a new RangeControl component is in the pipeline.
This PR likely needs a rebase/merge from trunk to get e2e to pass |
…#49105) Co-authored-by: chad1008 <[email protected]>
For the dev note, see #46741 |
What?
Add support for the
size="__unstable-large"
prop within the RangeControl component, to support the effort towards consistent components across the board re #46734.Related to #49101 and #46741.
Why?
Support the consistent component effort in #46734.
How?
size(20)
.size="__unstable-large"
to the Cover block's Overlay Opacity control for testing.Testing Instructions
Screenshots or screencast
Before:
After: